The present application is related to U.S. patent application Ser. No. 08/387,501, entitled Method and System For Switching Between Usrs In A Conference Enabled Application; U.S. patent application Ser. No. 08/387,501 now U.S. Pat. No. 5,887,170, entitled Management And Classification Of Events For An X Windows Conferencing Enabler, U.S. patent application Ser. No. 08/387,502 now U.S. Pat. No. 6,219,044, entitled Method For Managing Top-Level Windows Within A Conferencing Network System, U.S. patent application Ser. No. 08/387,503 now U.S. Pat. No. 5,715,392, entitled Method For Managing Visual Type Compatibility In A Conferencing Network System Having Heterogeneous Hardware, U.S. patent application Ser. No. 08/387,505, entitled Method For Managing Pixel Selection In A Network Conferencing System, U.S. patent application Ser. No. 08/387,506 now U.S. Pat. No. 5,640,540, entitled Method And Apparatus For Translating Key Codes Between Servers Over A Conference Networking System, all filed of even date herewith by the inventors hereof and assigned to the assignee herein, and incorporated by reference herein.
1. Technical Field
The present invention relates, generally, to application conferencing over a network system and, more specifically, to a method for a conferencing enabler to support applications that use either shareable or non-shareable colorcells while running in a conference in which various servers on the network system support different visual classes. More specifically still, the present invention is directed towards a method that allows applications to run in conference mode over the network system with colors as close as possible to that requested by the application, based on the capabilities of each server in the conference.
2. Description of the Related Art
Operating under X Windows provides distributed client/server support for two dimensional graphics. The X server manages the display for the application, two dimensional graphics within the window. The X Window conferencing enabler appears to the application to be an X server, while at the same time appearing to the X server as an application, as shown below. The X Windows conferencing enabler then connects to multiple X servers on behalf of the application, displaying the application""s windows on each display. The application is not aware that it is being displayed on multiple X servers. Such a networking system is fully described in commonly assigned patent application Method And System For Switching Between Users In A Conference Enabled Application, Ser. No. 08/387,500 now U.S. Pat. No. 5,557,725, incorporated herein by reference for all purposes.
In the absence of a conferencing enabler, the application connects to an X server and communicates with it using X protocol, and asks the X server to create resources such as X windows on the server. In addition, the X server has resources that it has defined that may be used by any application that is connected to that server. In general, resources that are created by the server are those that describe the environment of that server. Many of these resources are provided to the application when it initially connects to the X server. X server defined resources include a defined set of visual types that indicate the ways that the server may be used to display colors. Every application that creates a window to display graphics on that server must use one of these types. Every X server indicates which of these visual types is its default visual type.
There are six visual classes supported by X windows, of which any server may support one or several. When an application needs to display an object of a given color, the application must first xe2x80x9callocatexe2x80x9d colorcell. This will reserve that colorcell (referred to by a pixel value), prior to using it. Depending upon the way in which the pixel is allocated, the application must use some means to indicate to the server the color (that is, the red, green and blue intensities) that the pixel should represent. The X server will display the color that is as close as possible to that requested by the application. (The ability of the X server to display a given color is ultimately determined by the graphics adaptor which it is using.)
Of these six visual classes, three of them allow an application to change the entries in the associated colormap (that is, they allow entries in the colormap to be allocated as read/write) and three of them do not. These classes are separated as follows:
Read only colorcells are made available to the other applications using the X server as well, thus they are xe2x80x9cshareablexe2x80x9d colorcells. Non-shareable colorcells are those that are allocated as read/write cells, and cannot be allocated by other applications. When an application allocates a colorcell as non-shareable (with an AllocColorCells or AllocColorPlanes request), the red, green and blue values associated with that colorcell are not initialized. It is the application""s responsibility to set the desired red, green and blue values with a StoreColors or StoreNamedColor request. If an application attempts to use a pixel value without first allocating it and, if required, initializing it, the application has no guarantee as to what actual color will be displayed. In addition, if an application attempts to initialize a colorcell that It has not allocated, it will receive an AccessError.
The behavior of the X server in response to a request to allocate an entry differs based on the visual type which is being used. The conditions are summarized in the following table:
A problem arises when the X Windows conferencing enabler distributes an application to X servers which differ in their available visual types. When the application connects to the conferencing enabler, the enabler must inform that application which visual types are available. From that point forward, the application is able to use any and/or all of those visual types and the conferencing enabler must support the application""s use of the visual types. This must be true, even if another X server with significantly different visual types joins a conference after the application has been made aware of its available visual types.
Therefore, if an application is using a visual type that supports solely read/write pixel allocations, the conferencing enabler must be able to simulate that behavior for X servers in the conference that do not have read/write visual types available. Specifically, the conferencing enabler must be able to simulate the following behavior in this case,
1. If the application believes it is using a read/write visual class, it can expect to receive AllocError(s) (meaning the X server could not allocate a shareable cell) when it attempts to allocate any type of colorcell. It would be the application""s responsibility to react appropriately to such an error.
2. If an application attempts to initialize a colorcell that it has not allocated, it should receive an AccessError.
3. The application should get the closest colors available on each X server to what it requests.
4. Colorcells that are used without being explicitly allocated or initialized will display as xe2x80x9cunpredictablexe2x80x9d colors. That is, the exact color displayed is determined by the history of the X server, and is unknown to the application.
In a similar manner, if an application is using a visual type that supports solely read/only allocations, the conferencing enabler must be able to simulate that behavior for X servers in the conference that do not have read/only visual types available. Specifically, the conferencing enabler must be able to simulate the following behavior in this case.
1. If the application believes it is using a read/only visual class, it can not receive AllocErrors (meaning the X server could not allocate a shareable cell) when it attempts to allocate a shareable colorcell.
2. The application should get the closest colors available on each X server to what it requests.
3. Colorcells that are used without being explicitly allocated will display as unpredictable colors.
If the X conferencing enabler does not compensate for the differences in visual types in a conference, applications that attempt to allocate either shareable or non-shareable colorcells would not be able to run within a conference in which all of the X servers did not support this type of allocation.
Accordingly, what is needed is a method for an X windows conferencing enabler to support applications that use either shareable or non-shareable colorcells while running in a conference in which the various X servers have different support of their respective visual classes. Additionally, what is needed is a method to allow the applications to run with the desired colors as close as possible to that requested by the application, based upon the capabilities of each X server in the conference.
It is therefore one object of the present invention to provide application conferencing over a network system.
It is another object of the present invention to provide a method for a conferencing enabler to support applications that use either shareable or non-shareable colorcells while running in a conference in which various servers on the network system support different visual classes.
It is yet another object of the present invention to provide a method that allows applications to run in conference mode over the network system with colors as close as possible to that requested by the application, based on the capabilities of each server in the conference.
The foregoing objects are achieved as is now described. According to the present invention, a method for an X windows conferencing enabler to support applications that use non-shareable color cells while running in a conference in which the various X server participants differ in their support of visual classes is disclosed. In the method, an application requests to allocate and initialize non-shareable colorcells and is displayed in a conference such that the colors for each X server participant are as close to that requested by the application as the hardware supports. The conference enabler distributes all of the non-shareable requests to each participant in the conference that supports the requests. For those participants that do not support those requests, a no operation request is sent in place of the allocation requests and an allocate color or allocate named color order is sent in place of the initialization request. Errors and replies are moderated so that the application only receives those errors and replies that are consistent with its X server""s expected behavior.
Also presented is a method to support X Windows conference enabled applications that allocate shareable colorcells by a conference enabler. This is accomplished by distributing the AllocColor and AllocNamedColor to each participant in the conference and then returning the master""s reply or error to the application, the conference enabler is able to support heterogeneous hardware for such applications. The enabler must also reset the X servers that allocated colorcells successfully if the master did not. On the other hand, incompatible X servers are prevented from interacting with the application in the future if they receive an error when the master is successful.
The above as well as additional objects, features, and advantages of the present invention will become apparent in the following detailed written description.